This application generally relates to packet data networks, and more specifically to filtering and gating data in packet data networks using policy mechanisms.
Originally, packet data networks, such as Internet Protocol (xe2x80x9cIPxe2x80x9d) networks, were designed to carry xe2x80x9cbest effortxe2x80x9d traffic. That is, the network did not guarantee that a user packet would arrive at the destination. Because of the market success of IP networks, there is today a clear requirement for mechanisms that allow IP networks to support various types of applications. Some of these applications have quality-of-service (xe2x80x9cQoSxe2x80x9d) requirements. Examples of such applications include various real time applications (IP Telephony, video conferencing), streaming services (audio or video), or high quality data services (browsing with bounded download delays). Recognizing these requirements, the Internet Engineering Task Force (xe2x80x9cIETFxe2x80x9d), which is the main standards body for IP networking, recently standardized a set of protocols and mechanisms that enable IP network operators to build QoS-enabled IP networks.
FIG. 1 depicts a simplified high-level model of an IP network which may be useful in explaining QoS provisioning. As can be appreciated, the model includes two users, but could easily be expanded to include more users without changing the basic functionality of the network.
In FIG. 1, User-A 101 may communicate with User-B 102 or with an application server 103. For example, in the case of an IP telephony session, User-A 101 may communicate with User-B 102. Similarly, in the case of streaming services, User-A 101 may communicate with the application server 103, which may be configured as a video server. In either case, User-A 101 accesses an IP backbone network 104 through a local access network 105, such as a telephone, Global System for Mobile Communications (xe2x80x9cGSMxe2x80x9d), or Universal Mobile Telecommunication System (xe2x80x9cUMTSxe2x80x9d) network. User-B 102 is similarly connected to the IP network 104 through local access network 106. It will be appreciated that User-A and User-B need not use the same type of access network, however.
As is generally known, the IP network 104 may include a number of IP routers and interconnecting links that together provide connectivity between the IP network""s ingress and egress points and thereby make two party communication possible.
As far as the users are concerned, the perceived QoS depends on the mechanisms both in the access networks 105, 106 and on the IP backbone network 104. Of particular interest is the specific case where at least one of the access networks is a UMTS network.
When users access IP based services, they typically use a device that runs an application program that provides the interface for the user to access the particular service. For instance, in FIG. 1, User-A may use a laptop computer running a conferencing application program to attend an IP network based meeting, where participants of the meeting collaborate using various programs. Such programs are well known in the art.
Various applications may access network services through an application programming interface (xe2x80x9cAPIxe2x80x9d). An API provides application programmers with a uniform interface to access underlying system resources. For instance, an API may be used to configure the network resource manager to require that a particular IP packet originating from a given application receive a certain treatment from the network, such as a particular QoS. For example, if the IP network is a Differentiated Services IP network, then an application program may request that all of its IP packets receive the xe2x80x9cExpedited Forwardingxe2x80x9d treatment.
Note that the User (and the API in the user""s equipment) may not be aware of the different technologies that various access networks and IP backbone networks employ in order to provide end-to-end QoS. For instance, the user may use an RSVP/IntServ based API and the end-to-end embodiment in which the user is involved may include a UMTS access network and a non-RSVP enabled IP network. In such cases, some interworking mechanisms between the various technologies may be needed to make sure that QoS is provided end-to-end.
Integrated Services (xe2x80x9cIntServxe2x80x9d) provide the ability for applications to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required. First, individual network elements, such as subnets and IP routers, along the path followed by an application""s data packets must support mechanisms to control the QoS delivered to those packets. Second, a way to communicate the application""s requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.
IntServ defines a number of services such as Controlled-Load (defined in IETF RFC 2211) and Guaranteed (defined in IETF RFC 2212). The service definition defines the required characteristics of the network equipment in order to deliver the service. For example, guaranteed service provides firm, mathematically-provable bounds on end-to-end datagram queuing delays and makes it possible to provide a service that guarantees both delay and bandwidth. Controlled-load service provides the client data flow with a QoS closely approximating the QoS that the same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded. The individual network elements (subnets and IP routers) that support the service must comply with the definitions defined for the service.
The service definition also defines the information that must be provided across the network in order to establish the service. This function may be provided in a number of ways, but is frequently implemented by a resource reservation setup protocol such as RSVP (defined in IETF RFC 2205).
RSVP (Resource reSerVation Protocol) is a resource reservation setup protocol designed for an IntServ Internet (defined in IETF RFC 1633, 2205, and 2210). The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path.
FIG. 2 shows the End-to-End Integrated Service between the hosts. The service is provided using routers and hosts that support the service definition defined for the required service and through signaling of the relevant information between the nodes.
Since RSVP is a protocol that is primarily designed to be end-to-end, some extra functionality is required in a situation where the sender would like to use RSVP for resource reservation in only some portion of the end-to-end path. This may arise if RSVP is used in an access network and over-provisioning is used in the backbone network. In such situations the concept of the RSVP Proxy is useful.
The RSVP Proxy is a functionality provided by a network device, such as a router or a switch, in which the network device originates the RESV message in response to an incoming PATH message on behalf of one or more receivers identified by the PATH message. In other words, the RSVP Proxy acts on behalf of the remote host and thereby facilitates resource reservation between the originating host and the RSVP Proxy. This is shown in FIG. 3. The RSVP Proxy may use knowledge of network conditions between the RSVP Proxy and the non-RSVP host.
Differentiated Services (xe2x80x9cDiffServxe2x80x9d) enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; the services include those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., xe2x80x9cclassxe2x80x9d differentiation). Services may be constructed by a combination of setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts), using those bits to determine how packets are forwarded by the nodes inside the network, and conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.
Differentiated Services defines an edge router at the network boundary, and core routers within the network. The edge and core routers have different duties. The edge router must condition the traffic to ensure that the traffic conforms to the service agreement. The edge router also marks the packet traffic with the appropriate Differentiated Services Code Point (xe2x80x9cDSCPxe2x80x9d) and then forwards the packets according to the service behavior defined for that DSCP. The service behavior, called the Per Hop Behavior (xe2x80x9cPHBxe2x80x9d) may define the prioritization or weighting of that type of traffic to give the traffic better service than other traffic of a different type. The core nodes examine the DSCP and apply the service behavior appropriate for that service.
FIG. 4 shows the end-to-end service. The DS edge routers perform the traffic conditioning, while the DS core routers simply apply the PHB.
The IntServ architecture provides a means for the delivery of end-to-end QoS to applications over heterogeneous networks. To support this end-to-end model, the IntServ architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services may be viewed as a network element in the total end-to-end path.
From the perspective of IntServ, DiffServ regions of the network are treated as virtual links connecting IntServ capable routers or hosts (much as an ethernet LAN can be treated as a virtual link). Within the DiffServ regions of the network, routers implement specific PHBs (aggregate traffic control). The total amount of traffic that is admitted into the DiffServ region that will receive a certain PHB is controlled by the conditioning at the edge routers. An IntServ service can be provided across a DiffServ domain by applying admission control and traffic conditioning at the edge router, and signaling using RSVP across the DiffServ domain. The information provided in the RSVP signaling should be appropriate for the service across the DiffServ domain. This is shown in FIG. 5.
To realize a QoS Bearer Service with clearly defined characteristics and functionality, the bearer must be set up from the source to the destination of the service. A bearer service includes all aspects to enable the provision of a contracted QoS. These aspects are among others the control signaling, user plane transport, and QoS management functionality.
Mobile Access Data Networks, including General Packet Radio Service (xe2x80x9cGPRSxe2x80x9d) and UMTS, may form a part of the overall network and play an important role in the end-to-end bearer service for customers connected to it. Hence, the service provided over the GPRS/UMTS network must be suitable in the aspects mentioned above of control signaling and user plane transport to provide the required end-to-end bearer service.
The GPRS/UMTS network includes a set of network elements between the host, such as a Mobile Station (xe2x80x9cMSxe2x80x9d), for example, and the external packet switching network the user is connecting to. The host may also be one of several network communication devices, such as a computer, personal data assistant (xe2x80x9cPDAxe2x80x9d), etc. A MS host is shown in FIG. 6 for illustrative purposes.
The Gateway GPRS Support Node (xe2x80x9cGGSNxe2x80x9d) provides the interworking with external packet-switched networks.
In order to send and receive packet-switched (xe2x80x9cPSxe2x80x9d) data, the MS shall activate the Packet Data Protocol context that the MS wants to use. This operation makes the MS known in the corresponding GGSN and interworking with external data networks can commence.
User data is transferred transparently between the MS and the external data networks with a method known as encapsulation and tunneling: data packets are equipped with PS-specific protocol information and transferred between the MS and the GGSN.
QoS has an extremely important and central role in Third Generation (xe2x80x9c3Gxe2x80x9d) mobile networks as well. QoS is a means for providing end users with satisfying service and also is essential for network management in terms of knowledge. QoS implies knowledge of the traffic in the network and thus QoS also enables efficient use of the spectrum resources.
The invention will be described in terms of a UMTS QoS architecture. Accordingly, in order to provide a uniform level of understanding, a state-of-the-art overview of QoS in UMTS is provided. The Third Generation Partnership Project (xe2x80x9c3GPPxe2x80x9d) UMTS QoS architecture is described, including an explanation of the Packet Data Protocol (xe2x80x9cPDPxe2x80x9d) context, the traffic flow template (xe2x80x9cTFTxe2x80x9d), and the QoS maintenance procedures for activated UMTS bearers.
It is expected that bandwidth associated with radio is the most expensive and precious resource in the end-to-end chain. Within UMTS access networks, the radio network resources are managed on a per PDP context granularity, which corresponds to a user flow and a certain QoS level.
The QoS framework for R99 3G networks is specified in TS23.107 V.3.4.0. The main focus is on the QoS architecture to be used in the UMTS level, where the list of QoS attributes applicable to UMTS Bearer Service and the Radio Access Bearer Service are specified along with appropriate mapping rules.
TS23.060 V.3.4.0 specifies the general mechanisms used by R99 3G networks for PS connectivity services in the UMTS level. This defines the service description for the packet domain of the 3G network, which includes the GPRS in GSM and UMTS.
In a UMTS QoS Architecture, network services are considered end-to-end, from a Terminal Equipment (xe2x80x9cTExe2x80x9d) to another TE. An End-to-End Service may have a certain QoS, which is provided to the user of a network service.
To realize a certain network QoS, a Bearer Service with clearly defined characteristics and functionality is set up from the source to the destination of a service. The bearer service includes all aspects to enable the provision of a contracted QoS, e.g., control signaling, user plane transport, QoS management functionality, etc.
A UMTS bearer service layered architecture is depicted in FIG. 7. Each bearer service on a specific layer offers its individual services using services provided by the layers below. Bearers are broken down into underlying bearers, each one providing a QoS by a realization that is independent of the other bearers. Service agreements are made between network components, which are arranged vertically in FIG. 7. The service agreements may be executed by one or more layers of service.
For instance, the UMTS bearer service includes a Radio Access Bearer (xe2x80x9cRABxe2x80x9d) service and a Core Network (xe2x80x9cCNxe2x80x9d) bearer service. The RAB service is then divided into a radio bearer service and a lu bearer service. The lu interface is the interface between the radio access network and the core network.
The following are examples of the entities shown in FIG. 7. The terminal equipment (xe2x80x9cTExe2x80x9d) may be a laptop computer and the mobile terminal (xe2x80x9cMTxe2x80x9d) may be a handset, e.g., a mobile station. The UMTS Terrestrial Radio Access Network (xe2x80x9cUTRANxe2x80x9d) may be made up of a combination of Node B and a Radio Network Controller (xe2x80x9cRNCxe2x80x9d). The CN lu Edge Node may be a Serving GPRS Support Node (xe2x80x9cSGSNxe2x80x9d) and the CN Gateway (xe2x80x9cGWxe2x80x9d) may be a GGSN.
The QoS management functions in UMTS are used to establish, modify and maintain a UMTS Bearer Service with a specific QoS, as defined by specific QoS attributes. The QoS management functions of all UMTS entities combined ensure the provision of the negotiated UMTS bearer service.
The UMTS architecture comprises four management functions in the control plane and four in the user plane. The control plane management functions are:
Bearer Service (xe2x80x9cBSxe2x80x9d) Manager, which sets up, controls, and terminates the corresponding bearer service. Each BS manager also translates the attributes of its level to attributes of the underlying bearer service during service requests.
Translation function, which converts between external service signaling and internal service primitives including the translation of the service attributes, and is located in the MT and in the GW.
Admission/Capability control, which determines whether the network entity supports the specific requested service, and whether the required resources are available.
Subscription Control, which determines whether the user has the subscription for the bearer being requested.
The user plane management functions are:
Mapping function, which marks each data unit with the specific QoS indication related to the bearer service performing the transfer of the data unit. For example, the mapping function may add DiffServ code points to packets before putting the packets on the lu or CN bearer.
Classification function, which resides in the GGSN and in the MT, assigns user data units (e.g., IP packets) received from the external bearer service (or the local bearer service) to the appropriate UMTS bearer service according to the QoS requirements of each user data unit. This is where the traffic flow template (xe2x80x9cTFTxe2x80x9d) and packet filters are situated, as described below.
Resource Manager, which distributes its resources between all bearer services that are requesting use of these resources. The resource manager attempts to provide the QoS attributes required for each individual bearer service. An example of resource manager is a packet scheduler.
Traffic conditioner, which is a shaping and policing function which provides conformance of the user data traffic with the QoS attributes of the concerned UMTS bearer service. Traffic conditioner resides in the GGSN and in the MT as well as in the UTRAN.
The QoS management functions for controlling the UMTS bearer service are shown in FIG. 8. The purpose of these control functions is to support establishment and modification of UMTS bearer services through interaction with the Local Service Control in the TE, and the External Service Control in the External Network.
The QoS management functions of the UMTS bearer service in the user plane are shown in FIG. 9. These functions together maintain the data transfer characteristics according to the commitments established by the UMTS bearer service control functions, expressed by the bearer service attributes. The user plane uses the QoS attributes. The relevant attributes are provided to the user plane management functions by the QoS management control functions.
Four different QoS classes are standardized in UMTS and are shown in FIG. 10. Data transport may be optimized for the corresponding type of application data or for a bearer service of a certain class. The main distinguishing factor between these classes is how delay sensitive the traffic is: Conversational class is meant for traffic which is very delay sensitive (for real-time services) while Background class is the most delay insensitive traffic class (for non-real time services).
To characterize a bearer service in detail, a set of bearer service attributes are standardized in UMTS as shown in the tables below. A certain QoS is requested by selecting a set of attribute values that describes the bearer requirement. Parameters differ depending on the type of bearer service requested.
FIG. 11 shows which attributes that are applicable to which traffic class. FIG. 12 provides an overview of what the different QoS attributes are used for. The exact definitions of the QoS attributes can be found in TS23.107, which is currently at version 3.4.0.
A subscription is associated with one or more PDP addresses, i.e. IP addresses in the case of IP traffic. Each PDP address is described by one or more PDP contexts stored in the MS, the SGSN, and the GGSN. Default values are also available in the HLR which holds the subscription information. Each PDP context may be associated with a Traffic Flow Template (xe2x80x9cTFTxe2x80x9d). At most one PDP context (associated with the same PDP address) may exist at any time with no TFT assigned to it. The relationship between PDP address, PDP context, and TFT is provided in FIG. 13.
A PDP context is a dynamic table of data entries, comprising all needed information for transferring PDP PDUs between MS and GGSN, for example addressing information, flow control variables, QoS profile, charging information, etc. The relation between UMTS bearer services and PDP context is a one to one mapping, i.e. if two UMTS bearer services are established for one PDP address, two PDP contexts are defined.
The PDP context procedures are standardized in TS23.060, which is currently at version 3.4.0. The concepts surrounding the QoS profile and the Traffic Flow Template (xe2x80x9cTFTxe2x80x9d) are relevant from the QoS perspective.
The UMTS QoS attributes have been selected and defined mainly for supporting efficient radio realization. A QoS profile is defined by a set of UMTS QoS attributes. The RNC obtains the pertinent RAB QoS profile from the SGSN during PDP context activation. There are three different QoS profiles involved in a PDP context activationxe2x80x94the requested QoS profile, the negotiated QoS profile, and the subscribed QoS profile (or the default QoS profile).
Depending on the type of information needed, the stored PDP context information differ in the MS, RNC, SGSN, GGSN, and HLR, as listed in Table 1.
A TFT is a packet filter (or set of filters) that associates packets to the correct PDP context, ensuring that packets are forwarded in the appropriate GPRS Tunneling Protocol (xe2x80x9cGTPxe2x80x9d) tunnel. The TFT enables the possibility of having several PDP contexts with varying QoS profiles, associated to a single PDP address. The TFT is managed and initiated by the MT both for the uplink and downlink flows. The uplink TFT resides in the MT, while the downlink TFT resides in the GGSN. The downlink TFT is sent from the MT to the GGSN during PDP context activation/modification. The downlink TFT""s may be added to a PDP context that was created without one, and the contents may be modified as well.
FIG. 14 shows the TFT packet filter attributes and valid combinations. Each TFT has an identifier and an evaluation precedence index that is unique within all TFT""s associated with the PDP contexts that share the same PDP address. The MS manages the identifiers and the evaluation precedence indexes of the TFT""s, and as well as the packet filter contents.
Some of the attributes in FIG. 14 may coexist in a packet filter while others mutually exclude each other. Only those attributes marked with an xe2x80x9cXxe2x80x9d may be specified for a single packet filter. All marked attributes may be specified, but at least one has to be specified.
The PDP context signaling is the means for carrying the requested and negotiated QoS profile between the nodes in the UMTS network. PDP context signaling has a central role for QoS handling in terms of admission control, negotiation, and modifying of bearers on a QoS level. The PDP context signaling message exchanges are described below with reference to the numerals in FIG. 15.
In step 1, an RRC connection is established. This procedure is needed to establish a connection between the MS and the UTRAN. However, from a QoS perspective, the establishment phase typically does little more than indicating the type of radio channel that is being used.
In step 2, the MS sends a PDP message to the SGSN to activate the PDP context. The requested QoS profile is included in this message. At this stage, the SGSN makes an admission check and might restrict the requested QoS if the system is overloaded.
In step 3, the SGSN sends a RANAP message, xe2x80x9cRAB Assignment Requestxe2x80x9d, to the RNC. RANAP, or radio access network application part, is an application protocol for supporting signaling and control transmission between the Radio Access Network (xe2x80x9cRANxe2x80x9d) and the external CN. RANAP permits communication between the RAN and circuit-switched or packet-switched networks. This request to establish a radio access bearer service carries the RAB QoS attributes, which may have been modified by the SGSN.
In step 4, the RNC uses the RAB QoS attributes to determine the radio related parameter corresponding to the QoS profile. These parameters may include transport format set and transport format combination set. In addition, the UTRAN performs an admission control on this bearer.
In step 5, the RNC sends an RRC message, xe2x80x9cRadio Bearer Set-up,xe2x80x9d to the MS. The RRC message includes the radio related parameters that were determined in step 4.
In step 6, the UTRAN and the MS apply the radio parameters and are ready to transfer traffic. To signal this, the MS sends a xe2x80x9cRadio Bearer Set-up Completexe2x80x9d RRC message to the RNC.
In step 7, the UTRAN sends a xe2x80x9cRAB Assignment Completexe2x80x9d RANAP message to the SGSN.
In step 8, a Trace procedure may be initiated. This is an operation and maintenance function for surveying subscribers.
In step 9, the SGSN sends a xe2x80x9cCreate PDP Context Requestxe2x80x9d to the GGSN, carrying the QoS profile. However, the QoS profile may have different parameters than those requested by the MS in step 2. Based on this profile, an admission control is performed at the GGSN level and the GGSN may restrict the QoS if, for example, the system is overloaded. The GGSN stores the PDP context in its database.
In step 10, the GGSN returns the negotiated QoS to the SGSN in a xe2x80x9cCreate PDP Context Responsexe2x80x9d message and the SGSN stores the PDP context in its database.
In step 11, the negotiated QoS is sent from the SGSN to the MS in a xe2x80x9cActivate PDP Context Acceptxe2x80x9d message. If either the SGSN or the GGSN has modified the QoS profile, then the MS has to either accept or reject this profile.
There are several local admission controls taking place in the procedure. However, since bandwidth associated with radio is the most expensive resource, the UTRAN is consulted in determining whether radio resources are available or not during PDP context activation or modification. Thus, admission control in UMTS is performed in a radio centric manner.
To provide IP QoS end-to-end, it is necessary to manage the QoS within each domain. An IP BS Manager in the Gateway is used to control the external IP bearer service. Due to the different techniques used within the IP network, this communicates to the UMTS BS manager through the Translation function.
There is a likewise a need for an IP bearer service manager function to be provided in UE, where the bearer service manager maps the QoS requirements of the application to the appropriate QoS mechanisms.
FIG. 16 shows the embodiment for control of an IP service using IP BS Managers in both possible locations in the UE and Gateway node. FIG. 16 also indicates the optional communication path between the IP BS Managers in the UE and the Gateway node.
The IP BS Managers use standard IP mechanisms to manage the IP bearer service. These mechanisms may be different from mechanisms used within the UMTS, and may have different parameters controlling the service. The translation/mapping function provides the interworking between the mechanisms and parameters used within the UMTS bearer service and those used within the IP bearer service, and interacts with the IP BS Manager.
If an IP BS Manager exists both in the UE and the Gateway node, it is possible that these IP BS Managers communicate directly with each other by using relevant signaling protocols.
An IP Multimedia service (xe2x80x9cIMSxe2x80x9d) is defined on top of GPRS bearer service. The IP Multimedia service provides multimedia sessions to the user. QoS aspects of bearers supporting IP multimedia is specified in TS 23.207 and the IP Multimedia (xe2x80x9cIMxe2x80x9d) specification is in TS 23.228.
The IMS is based on IP application signaling, such as, for example, Session Initiation Protocol (xe2x80x9cSIP/SDPxe2x80x9d). An end-user requests a session on a signaling GPRS bearer, which must be established prior to the session setup. FIG. 17 illustrates the interrelation of an IP Multimedia system to GPRS bearers. GPRS bearers are established between terminal A or B 1700, 1750 and a respective gateway 1720, 1770 between a UMTS network 1710, 1760 and the backbone 1740. The gateway also serves as an aggregation pont for the traffic from several GPRS users.
One GPRS bearer carries the application level signaling 1780 (such as SIP/SDP) that will be exchanged with the remote terminals 1700, 1750 to setup an IM session. The application is supported by one or several proxies in the network. To carry the actual media streams, one GPRS bearer is then established up to the aggregation point 1720, 1770 for each media stream. When resources are available end-to-end, by dedicated GPRS bearers and by access to the shared aggregated transport through the backbone, the multimedia session is connected and may start. Thus a number of parallel GPRS bearers are established to support a multimedia session.
Generally speaking, QoS protocols provide the mechanisms to reserve necessary network resources and to differentiate the traffic, while policy rules define how they are used. For instance, the IETF QoS mechanisms RSVP and IntServ define a resource reservation setup protocol and a set of service definitions, respectively. However, the admission control mechanism of IntServ does not include an important aspect of admission control. More particularly, network managers and service providers must be able to monitor, control and enforce the use of network resources and services based on policies derived from criteria, such as: the identity/authority level of users and applications (e.g. managers, engineers, trainees, etc.); traffic bandwidth requirements (e.g. narrow band, wide-band, etc.); security considerations (e.g. access to mission critical resources); and time-of-day/week.
Since there are varying circumstances in which traffic owners, end-users, applications, Internet hosts, etc., are entitled to the services they request, there is a need for rules, a need for enforcement methods of these rules and a need for a xe2x80x9cjudgexe2x80x9d to decide when they apply. Consequently, the three major components of a policy system is the policy rules and their storage (typically in a policy database), the enforcement methods using policy enforcement points (xe2x80x9cEPxe2x80x9d), and the policy decision points (xe2x80x9cDPxe2x80x9d). Additionally, the IETF has standardized a protocol for information exchange between EP""s and DP""s under the term Common Open Policy Service (xe2x80x9cCOPSxe2x80x9d).
A policy may be regarded as a collection of rules that result in one or more actions when specific conditions exist. The IETF Policy Framework is illustrated in FIG. 18. The separation between EP and DP, and also DP and the Policy Repository, is a logical one based on functionality and open interfaces, and not necessarily a physical separation. Also, there are typically multiple EP""s in a network domain, with multiple interfaces on each EP possible as well. For instance, all or some routers of an administrative domain may implement the EP functionality in an IP network, and a central server may implement the DP functionality in that domain. The DP in turn may be connected to a Policy (Rule) Repository and fetch data from it in order to make policy decisions. The Lightweight Directory Access Protocol (xe2x80x9cLDAPxe2x80x9d), for example, may be used as the protocol between the DP and the Policy Repository. The DP may communicate and export policy information to other network components, such as a network management entity, using other protocols, e.g., Simple Network Management Protocol (xe2x80x9cSNMPxe2x80x9d).
In a 3G network, the GGSN may be an appropriate EP, since the GGSN acts as a gateway node that can easily control 3G resources. The DP (often referred to as the Policy Server, xe2x80x9cPSxe2x80x9d) may reside inside or outside of the GGSN. Typically however, the DP is separated from the GGSN and there is an open interface between the PS and the GGSN.
Since the different functions of a policy system are located in separate logical entities, there is a need for policy transaction protocol(s), which function as the intermediary between the policy (database), the policy client (enforcer), and the policy server (decision maker). The policy transaction protocol is responsible for transferring the policy request and policy response between these two nodes. The de-facto standard for such a policy transaction protocol is the IETF standardized protocol COPS.
COPS is a simple query-and-response protocol for exchanging policy information between a policy server and its client(s). Once a policy server makes a decision, the policy client is responsible for the enforcement of that particular policy decision. COPS also has the unique feature of allowing the policy control decision to be communicated between the policy client and the policy server in order to determine the validity of that decision. While COPS is currently primarily used as an RSVP admission control protocol, the IETF is currently studying the idea of extending COPS to be a generalized policy communications protocol.
For operators providing both GPRS IP connectivity service and IP Multimedia service, there is a need to have the capability to handle the IMS users and the GPRS IP connectivity users differently for charging, prioritization, and other purposes. For example, a GPRS bearer of a high QoS bearer should only be permitted to be used to transport IMS media. This requirement may be logically extended to have control over different types of bearers, dependent on the subnetwork or service network they are connecting to, or the application that they are working towards. The requirement may also be logically extended to allow restriction of the GPRS bearer types to be controlled from an application.
The restrictions an operator may want to apply is, for example, strict control of the destination for data that is allowed to enter the network, because the service may have destination dependent charging and/or may be performing resource reservation for the connection.
If the charging is based on the time from IM session beginning through to IM session end, it is essential that the user cannot use these bearer resources without being charged, that is, the user should not be permitted to utilize the access network resources for any period without being charged.
Conventional GPRS and IMS mechanisms currently permits the bearer service to be established independent of the session state. The user is permitted to use the access network (e.g., UMTS) resources prior to the start of call charging, but a charging rate specific for the access bearer is applied for unauthorized data flow prior to the active phase. That is, the charge applied for the access bearer is different dependent on the current session state. If the session already exists, there may be no access bearer charge, but if it does not exist, there may be access bearer charges even if any data sent on the bearer is subsequently discarded. A disadvantage of using this method is that a very complex charging model is required.
In addition, resources that are not authorized and charged appropriately should not be reserved. However, in order to avoid voice clipping, the bearer must be available and established prior to the beginning of the session through event. Therefore, there are conflicting considerations.
Accordingly, there is a need to provide a better filtering and gating control of network data flow using policy mechanisms.
The present invention addresses these and other concerns by employing policy mechanisms using the architecture defined in TS 23.207 to provide policy driven filtering and gating of data flow over a QoS connection in a packet data network, such as a UMTS/GPRS network. The local SIP proxy server may be any local application server and a Policy Control Function (xe2x80x9cPCFxe2x80x9d) is located in a separate node, such as a policy server, with an interface between the application server and the PCF, and between the GGSN and the PCF.
According to one aspect, a method of filtering and gating data flow in a QoS connection between a remote host and user equipment in a packet data network using policy control mechanisms includes a remote host, or the user equipment, initiating an application in an application server, such as an SIP proxy server, a Real-Time Streaming Protocol (xe2x80x9cRTSPxe2x80x9d) server, or any type of IP based application server that supports an IP based application controlled by end-to-end signaling, and initiating a corresponding session between the remote host and the UE via the application server. The UE requests, to a GGSN of the network, establishment of a network bearer service between the UE and the remote host. A corresponding PCF in a policy server receives, from the application server, filtering data derived from session data received by the application server during the session. The GGSN interrogates the corresponding PCF in the policy server to initialize a gate using policy control filtering data at the GGSN. The gate then filters the data flow in the QoS connection according to the policy control filtering data.
According to a further aspect, the gate is opened when the application server sends an event trigger(s) to the policy server to request a gate opening and the policy server sends a corresponding gate open command to the gateway support node to open the gate. The gate is opened by the gateway support node to initiate the data flow in the QoS connection with the data flow being filtered by the according to the policy control filtering data.
According to still a further aspect, the gate is closed when the application server sends an event trigger(s) to the policy server to request a gate closing and the policy server sends a corresponding gate close command to the gateway support node to close the gate. The gate is closed by the gateway support node to end the data flow in the QoS connection. Also, the session is terminated by the application server and the network bearer service is terminated.
In another aspect, the application server exchanges information with the policy server over an open interface.
In yet another aspect, a COPS protocol is used to transfer policy decisions from the policy control function to the gateway support node. The policy control function acts as a COPS policy decision point and the gateway support node acts as a COPS policy enforcement point. The policy enforcement point controls access to QoS for a given set of IP packets that match a packet classifier. The policy decisions are either pushed to the gateway support node by the policy control function or the gateway support node requests policy information from the policy control function upon receipt of an IP bearer resource request.